TREES - A Tutorial on Using TREES.INC

This tutorial covers the correct usage of the trees.inc file, including several tips and tricks for most efficient usage. The trees.inc file utilizes a large number of variables to affect the appearance of the tree object being created; descriptions of these are provided in the accompanying tutorial on variables.

For the purposes of this tutorial, no extra effort will be put into making sure that only "nice" trees appear in the examples. As noted in the Tutorial on Variables, if a tree does not look right, the seed value of SD1 should be changed to different values until the desired effect is obtained. This does take some time to do, as it is usually necessary to perform several renders of different values before balance is achieved.

Including the Tree Object

Use of this trees.inc file has been greatly simplified from the previous version of this utility. To begin with, set up your scene file. Then, to insert a tree object, use the following code:

object {#include "trees.inc"}

That's it, in its simplest possible form. This will create a fairly realistic default tree made out of 1,340 cones and spheres, which can then be scaled, rotated, and translated as you desire. Of course, it's very unlikely that you'll always want to use the exact same tree object, which is where the many variables explained in the other tutorial come into play. They allow you to make many changes to the tree, some subtle, some extreme. They range from variables that affect the branching structure to different leaves, fruits, flowers, and textures. If you have not already read the other tutorial, you should do so before continuing, as this tutorial assumes that you have at least a basic understanding of what the variables do.

Working With Multiple Trees

The trees.inc file includes default settings for all of the available variables. There is also a default.inc file provided that resets all variables to these same default settings. The reason for this file being included is simple: if you use multiple different trees in your file, only the very first tree created will be created based on the default values; all subsequent trees will be based on the settings used for the trees directly proceeding them.

For example, suppose for my first tree I turned on the small red sphere fruits, and poplar bark, and use a BaseLen of 1.5, leaving everything else at the default values. For the second tree, I want dark green oak leaves and the default bark, everything else at the default values. Since the second tree is based on the values of the first, I'd have to turn off the fruits and poplar bark and turn on the oak leaves and dark green. And so on for each subsequent tree, always having to remember to restore the states of any variables changed in all of the proceeding tree definitions.

object {
#declare Tip=2
#declare BarkTexture=3
#declare BaseLen=1.5
#include "trees.inc"
translate <-7,0,0>
}

object {
#declare Tip=1
#declare BarkTexture=0
#declare BaseLen=1
#declare LeafShape=6
#declare LeafTexture=2
#include "trees.inc"
translate <7,0,0>
}

OR...I could include defaults.inc, which resets everything for me, and then just change the few variables that I really need to.

object {
#declare Tip=2
#declare BarkTexture=3
#declare BaseLen=1.5
#include "trees.inc"
translate <-7,0,0>
}

object {
#include "defaults.inc"
#declare LeafShape=6
#declare LeafTexture=2
#include "trees.inc"
translate <7,0,0>
}

There is a way in which this persistance of variables works as a useful feature; if I want to define a stand of five birch trees, I would set up my bark texture, branching angles, leaf shapes and textures and so on for the first tree only. Then, without including defaults, I can declare four more different birch trees just by including the trees.inc file again. If I want, I can also declare different SD1 values to adjust the appeareance of the extra trees.

object {
#declare BarkTexture=2
#declare LeafShape=3
#declare LeafTexture=3
#declare MinXDeg=25
#declare MaxXDeg=60
#declare LengthInc=1.25
#declare IncSplits=1.15
#include "trees.inc"
translate <-8,0,0>
}

object {
#include "trees.inc"
translate <8,0,0>
}

object {
#include "trees.inc"
translate <-8,0,8>
}
object {
#declare SD1=seed(15)
#include "trees.inc"
translate <8,0,8>
}
object {
#declare SD1=seed(24)
#include "trees.inc"
translate <0,0,4>
}

Using User-Defined Leaves, Fruit, or Flowers

One of the biggest improvements in this version is the ability to easily use user-defined shapes for the leaves, fruits, or flowers. This gives you a great amount of flexibility in the appearance of your tree. You can use the pre-defined shapes and textures, or you can create your own, making your tree as realistic or as alien as you'd like.

With user-defined objects, you must include your own texture statements as part of the object declaration. This has two advantages; first, it ensures that any texturing you wish to do of leaves, petals, parts of the fruits, etc., is applied exactly the way you wish it to be. Secondly, you can wait until after the tree has been declared to apply textures to the leaf, or fruit, or flower.

For example, suppose I want to make a tree with autumn leaves. I could simply apply a yellow/red texture to one of the existing leaf shapes - but if I do so, every single leaf on the tree will have the same mix of yellow/red on it. Real trees usually have a whole blend of colours among the leaves. The solution is to create a user-defined leaf without applying a texture to it. Then, once the trees.inc file has included, apply a texture. POV will put the texture on all objects in the tree that don't already have a texture, and therefore the leaves will end up having an "overall" texture applied to them.

object {
#declare IncSplits=1.1
#declare IncXDeg=2
#declare LeafShape=1
#declare Leave=
object {
sphere {<0,0,.195>,.2}
scale <.75,.1,1.5>
}
#include "trees.inc"
texture {
pigment {
bozo
color_map {
[0 color Yellow]
[1 color Red]
}
}
finish {
ambient .3
}
scale <3,3,3>
}
}

Keeping It Fast

The way the trees are created ensures that they render relatively rapidly, given the number of objects it takes to form them. However, parsing can still take quite a while, especially if you do much in the way of translating, rotating, or scaling the trees after they're created. Basically, you should try and restrict yourself to moving any tree only ONCE, directly to it's final position. Don't rotate them. Don't move them multiple times. Scale them using the BaseLen variable so that they're scaled as they're created, not after. Otherwise, your computer will sit there and chug, and chug, and chug, as it calculates and recalculates the positions of all of the thousands of objects making up the trees, consuming huge swathes of disk space in the process.

Please free to e-mail all comments, questions, suggestions, interesting "Tip" object code, typos, math errors, etc. to sonya_roberts@geocities.com. You are welcome to use, re-use, modify, pass on, pass around, pass up, and generally do whatever the heck you wish with this little .POV file of mine. My only request is that you acknowledge it's use in some way, shape, or form (especially if used for an entry in the Internet Raytracing Competition).

Sonya's Page of POV Stuff
Ms. Barrows' Consensual Reality